Temp-table basics
SmartDataObjects use a temp-table called RowObject as an intermediary for all data access. Data from a database is loaded into the RowObject table defined in an SDO. The data is then made available to client objects for viewing and updating.
Sometimes, the original source of the data might also be a temp-table. Perhaps the data is not coming in from an OpenEdgeŽ database (or OpenEdgeŽ DataServer), but is instead loaded into a temp-table by application code. The data might represent a set of calculations or summary records created by reading other database records. In any case, applications frequently use a temp-table as the original data source.
The Progress AppBuilder and SmartDataObject™ wizard support the definition of an SDO against a temp-table. A temp-table can be as complex as a database table. Its fields can have data types, formats, and other properties. The simplest way to define a temp-table that has a definition unlike any existing database table is to use the OpenEdgeŽ Data Dictionary to define the temp-table as if it were a real database table.
The AppBuilder supports a special naming convention for this. If you define a database and connect it using the logical database name, temp-db, the AppBuilder treats table definitions from this database specially. The AppBuilder recognizes the tables in this database as temp-table definitions when you build your SmartDataObjects. You might also want to use a temp-table that is identical to a database table, possibly with a few added fields. You can simply choose this table as the basis for your SDO as you build it. The following examples illustrate both of these cases.
Because there is no database table to serve as the data source, you must load the temp-table records yourself. You can do this easily either in the Main Block of the SDO or in a local initializeObject procedure.
As an example, create a temp-db database with a table TTMyTable in it, with two field definitions, Field1 and Field2. This is an example of a temp-table that is not derived from an actual database table. Therefore, you must define it in this “dummy” database so that both the AppBuilder and the Progress compiler can access the table definition at design time. When you run your finished application, however, you will not need to connect this database.
The Object Generator introduced in Chapter 5, "Using the Object Generator," generates SDOs and other objects for database tables. However, at present you cannot automatically generate SDOs for the temp-db in the Object Generator because it considers temp-db to be one of the special database names associated with the Repository, and excludes it from the drop-down list of databases to choose from.
|
To create an SDO in the AppBuilder: |
- From the New dialog box, select Static SmartDataObject, as shown:
- In the second page of the SDO wizard, fill in the SDO procedure name and other information that you want added to the comments section at the top of the source file.
- On the third page of the wizard, you must choose Define Temp-tables to choose your temp-db temp-table, as shown:
- In the Temp-Table Maintenance dialog box, choose Add.
- Select the temp-db database and your table name. The AppBuilder generates the
DEFINE TEMP-TABLETTMyTableLIKETTMyTablestatement, allowing the definition of the table to be compiled into the SDO without requiring that the table definition be available at run time. - Choose OK to return to the Temp-Table Maintenance dialog box, as shown:
- Choose OK to return to Page 3 of the wizard.
- Choose Define Query.
- Select that database name, then choose Add to add TTMyTable to the SDO query, as shown:
- On the fourth page of the wizard, choose Add Fields.
- Select fields from the temp-table as you would for any other table. Both fields are selected from our test temp-table, as shown:
- If you select the Advanced button in the Column Editor, you will see the Inherit Dictionary Validation option. This option is normally turned on when you build an SDO in the AppBuilder so that visual objects, such as SmartDataViewers, that use this SDO will inherit the Dictionary Field Validation that is executed when the user leaves each field. (It is automatically disabled for fields from temp-tables.) In this case it is off, as previously shown, because Progress temp-tables do not support field validation:
Now you must define the query for this table.
Because the AppBuilder recognizes the temp-db database as being special, it generates the alias temp-tables as the database name for any temp-tables you have defined.
